Source code for a programming language comprises a set of instructions written by a programmer. In a conventional (non interpreter-based) programming language, a compiler converts source code into object code for a specific platform. However, in an interpreter-based language such as Java, source code is compiled into bytecodes. An interpreter interprets the bytecodes at runtime, and may interpret one bytecode or instruction at a time. A java program may be platform-independent such that bytecodes can be interpreted and executed on any platform.
In a conventional programming language, for example C, the symbol table may be completely resolved at compile time. However, in an interpreter-based language like Java, bytecode parameters may need to be resolved into object references at runtime. An object reference is a reference to the address of that object in memory. For example, Java bytecodes may comprise parameters representing objects of the type CLASS, FIELD, or METHOD. Each such parameter is encoded as a small integer, called a Constant Pool Index, in a Java bytecode stream. During Java bytecode execution, a Constant Pool Index needs to be converted into its corresponding object reference. This conversion is called Constant Pool Resolution. Resolving parameters into their corresponding object references is time-consuming and utilizes valuable computer resources. Moreover, the same parameter may be resolved multiple times if the instruction with which it is associated is executed more than once. In an interpreter-based language, execution of bytecodes is slowed down because repeated resolution of parameters is required at runtime.
Traditional interpreters, for example a Java interpreter, save the costs associated with repeatedly resolving the same parameter by means of a technique called inline caching. In in-line caching, the first time an interpreter encounters an instruction during program execution, the interpreter resolves the parameters associated with the instruction. The interpreter then overwrites the associated parameters by their resolved object references, and overwrites the instruction with a different instruction whose parameters do not need to be resolved at runtime. During subsequent executions of an instruction, resolved object references are available to the interpreter without parameter resolution.
For example, in Java the instruction getstatic is used to read the value of a static field. The getstatic instruction has an associated parameter that represents a symbolic reference to the static field. In in-line caching, the first time a Java interpreter encounters a getstatic instruction, its associated parameter is resolved to the location of the field in memory. The interpreter then overwrites the associated parameter by the resolved value, and overwrites the getstatic instruction with a new instruction, getstatic_quick. During subsequent executions, the interpreter will use the resolved value to execute the getstatic_quick instruction without parameter resolution.
One problem with in-line caching is that it requires rewriting instructions. This in turn requires that the bytecodes be stored in a rewritable storage, for example Random Access Memory (RAM). In-line caching is impossible if the bytecodes being executed by an interpreter are stored in non-rewritable storage, for example Read-Only Memory (ROM). Another shortfall of in-line caching is that it changes the original bytecodes of a program; therefore, the program may no longer be copied for execution on another platform.
As the above discussion shows, in-line caching has significant drawbacks. Consequently, there exists a need for an improved mechanism for executing instructions which require parameters to be resolved at runtime.